I'm in favor of doing this.

To get the tests to pass, you'll need to ensure that "./gradlew check" passes. It looks like the formatting isn't what the "spotless" tool expects, and you can fix that by first running "./gradlew spotlessApply".

Thanks!

Two other things:

1. It'd be great to see a way to test to verify that this is really fixed. First choice would be a test case that formerly produced a StackOverflow error.
2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion, because I'm not sure how well users of Rhino are going to be able to handle having Rhino throw raw Java exceptions instead of some sort of JavaScript error, like by throwing the exception produced by ScriptRuntime.constructError.

1. It'd be great to see a way to test to verify that this is really fixed. First choice would be a test case that formerly produced a StackOverflow error.

I came across it only when a minor-version upgrade to the core-js package was installed; and the polyfill is quite convoluted and spread over a number of lines. I'm not confident it'll be at all easy to reproduce without pulling in the core-js code.

OTOH the original Rhino code says that it was just trying to reuse the code from the constructor of Error - I don't know if something's changed, but the code seems more straightforward this way.

Would you be comfortable if there was unit tests to show that it still works this way, i.e. rather than test for the stack overflow, test instead that the captureStackTrace still works as expected?

2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion

No problem, also the unit tests and formatting

2. I'm not sure how I feel about throwing an IllegalStateException in the case of recursion

No problem, also the unit tests and formatting

Ah - hang on, the problem would be that throwing a JavaScript error would cause the stack overflow exception; that throw should (in theory at least) never be thrown any more, but I had to add it so that I could set a breakpoint and catch the problem. Probably best if I just delete it?

How do you debug the javascript code as it is being run by rhino? I've got "a" debugger but only one that works inside of my framework.

Thanks for continuing to look at this. I have been able to use "normal" debuggers like the one built-in to VS Code with Rhino, but that's primarily to debug the Java code. For debugging the JavaScript directly it's a very different thing, although the debugger built in to Rhino (in the "toolsrc" directory) has given some people help in some circumstancesl.

#366 seems to be concerned with the same part of the code that creates a new object inside captureStackTrace

If this PR gets merged, the issue for which #366 got created likely is resolved as well (assuming it not already is somehow)

@johnspackman any update on this? Is there anything you need from us to move this forward?

@johnspackman any update on this? Is there anything you need from us to move this forward?

No update unfortunately; the issue I have is that in order to add a unit test, I'm struggling to reproduce it - what was failing for me is too big to include in a unit test, and a lack of debugger for the javascript made life hard. Although there is a debugger in toolsrc, I havn't had a chance to look at it, and AFAICR I also had issues with just running the existing unit tests. I think I ended up giving up because the simple task of "add a unit test" blew up into a large amount of work just to be able to get to the starting block, so to speak and I ran out of time

Converted to a draft as it's missing a testcase